In the field of transaction processing, units of work are generally required to have what are known as the ACID properties. ACID is an acronym representing the four unit of work properties of: Atomicity, Consistency, Isolation and Durability. Atomicity requires that either all the operations of the unit of work must be seen to occur or none must be seen to occur. Consistency requires a unit of work to maintain the consistency of in the data on which it operates. Isolation requires a unit of work not to read the intermediate results of another transaction. Durability requires the results of a committed unit of work to be made permanent and that the other ACID attributes can be guaranteed even in the event of system failure. However the responsibility to ensure these properties falls to different components. For example, if the unit of work is a transaction, atomicity is provided by the transaction manager, consistency by the application, isolation and durability by a resource manager. Further in some units-of-work not all such properties are observed, for example, isolation is not observed for a unit of work which is a long running (extended) transaction and which comprises several transactions.
For example, a well known and understood unit of work is a transaction and it is the role of a transaction manager or middleware to provide atomicity. Thus, for example, if an application involves two operations in a transaction and then requests the transaction service to commit the transaction, the transaction service must ensure that both operations commit (succeed). Alternatively if the application requests the transaction service to back out the transaction, the transaction service must ensure that both operations are backed out (fail).
A major problem in providing atomicity is that it must be guaranteed even in the event of a failure of the system on which the transaction service is. For example, if a transaction involves two operations and then commits, the system might fail after the transaction service has committed the first operation but before the same has been done for the second operation. As a result when the system is restarted the transaction service must ensure that the second operation also commits. In order to provide this functionality it is necessary for the transaction service to maintain a non-volatile log which survives a system failure and which records the progress of each transaction. For example the transaction service will maintain in the log a sequential record of the operations involved in each transaction and the progressive states of the transaction. Further, at certain points in the transaction the transaction must be paused whilst the transaction service ensures that a log record has been written to non-volatile storage. For example, if a transaction service is based on presumed rollback, when a transaction is committed the transaction service must ensure that a “committing” record is logged to non-volatile storage (forced to disk) before any of the operations involved in the transaction are committed. This is because if the first operation is committed and the system fails before the “committing” record is stored in non-volatile storage, on recovery, in the absence of a committing record for the transaction, the transaction service will assume rollback and then rollback the second operation thus breaking the atomicity of the transaction. However, in the modern day of very high transaction rates, the forcing of log records to non-volatile storage is relatively time consuming and a transaction service therefore tries to keep such forces to an absolute minimum.
A common requirement in an application is to follow one transaction with another for example if a first transaction backs-out, to then run a follow-on transaction which can, for example, attempt in some way to compensate for the failure and/or to report the occurrence of the failure. One problem with such a requirement is that completion of the first transaction is used to trigger the start of the follow-on transaction and a problem can occur if a system failure happens between completion of the first transaction and the starting of the follow-on transaction. This is because, on recovery ,the transaction service reads its log and recovers any incomplete transactions recorded in it. However in this scenario the first transaction is complete and the follow-on transaction is not in the log and as a result the requirement for it to run is lost.
IBM Patent U.S. Pat. No. 6,308,287 to IBM addresses this problem and discloses a solution in which: the back-out of the first transaction is interlocked with the start of the follow-on transaction such that the completion of the first transaction is not recorded in the log until after the existence of the follow on transaction is also recorded in the log; and “filed signals” are used to protect volatile in-memory signals which may be required during recovery. This way if a system failure happens after the completion of the first transaction, on recovery the transaction log will contain details of the follow-on transaction. However, this solution is not ideal because it requires much reprogramming of the transaction service in order to adopt the solution, and, further, it introduces additional forced log writes related to follow on transactions which introduce reduced performance in the processing of transactions.